Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Phase 1 of search services #46742

Merged
merged 26 commits into from
Oct 10, 2019

Conversation

stacey-gammon
Copy link
Contributor

@stacey-gammon stacey-gammon commented Sep 26, 2019

Summary

Introduction of the new pluggable search service. There are no actual users of this system yet except for the sample plugin which showcases the api's, and is functionally tested.

Fixes #43371

Jest test coverage

Screen Shot 2019-10-07 at 2 59 00 PM

Further exploration

The full exploration PR can be seen at #45058. This is just the first phase - the new client and server search extension points, as well as the ability to search Elasticsearch in a synchronous manner.

The async version has been tested in the fuller exploration PR.

Overview

Search service provides:

  • the ability for plugins to register new search strategies via it's setup contract
  • the ability for applications to use the search functionality via application mount context.
  • the ability for routes to use the search functionality via route mount context.

Client side interaction

Blank Diagram - Page 2

Client side + server side

Blank Diagram - Page 1 (2)

Client and server side api's differ slightly. On the client side, the search function returns an observable to support progress reporting. On the server side it is always a promise since we don't have a use case yet for a server side component wanting to handle progress, and client side progress strategy will require the server to always immediately return, to the client, all partial results as they come in.

Checklist

Use strikethroughs to remove checklist items you don't feel are applicable to this PR.

- [ ] This was checked for cross-browser compatibility, including a check against IE11
- [ ] Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support

  • Documentation was added for features that require explanation or tutorials
    • Documentation in the form of "living documentation" inside the search explorer sample plugin. Run via yarn start --plugin-path test/plugin_functional/plugins/demo_search/ --plugin-path test/plugin_functional/plugins/search_explorer/ and navigate to the search explorer app to view documentation, links and working demos using the search services.
  • Unit or functional tests were updated or added to match the most common scenarios

For maintainers

  • This was checked for breaking API changes and was labeled appropriately
    • this is net new
  • This includes a feature addition or change that requires a release note and was labeled appropriately
    • Skipping release notes as this API is too new to be documented or highlighted. It is still extremely volatile, and will be until we test it out with some real usage.

@stacey-gammon stacey-gammon added the release_note:skip Skip the PR/issue when compiling release notes label Sep 26, 2019
@elasticmachine
Copy link
Contributor

💔 Build Failed

@elasticmachine
Copy link
Contributor

💔 Build Failed

@elasticmachine
Copy link
Contributor

💔 Build Failed

@stacey-gammon stacey-gammon requested a review from a team as a code owner October 1, 2019 17:59
@elasticmachine
Copy link
Contributor

💔 Build Failed

@elasticmachine
Copy link
Contributor

💔 Build Failed

Comment on lines +32 to +37
await esArchiver.loadIfNeeded('../functional/fixtures/es_archiver/dashboard/current/data');
await esArchiver.load('../functional/fixtures/es_archiver/dashboard/current/kibana');
await kibanaServer.uiSettings.replace({
'dateFormat:tz': 'Australia/North',
defaultIndex: 'logstash-*',
});
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to revert these in an after?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yuuupppp, added another commit (and fixed the ts error that was killing ci)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

actually I reverted the data that was loaded. I don't think we need to change anything with the uiSettings, haven't seen that being "undone" before. Most tests set it explicitly.

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@stacey-gammon stacey-gammon requested a review from a team as a code owner October 3, 2019 18:02
Copy link
Contributor Author

@stacey-gammon stacey-gammon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@lukasolson and I pair programmed a bit on this so giving my official LGTM, and I think we only need one more in additional to Lukas's.

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

Copy link
Contributor

@spalger spalger left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Jest config changes LGTM

Copy link
Member

@ppisljar ppisljar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we add some documentation either to the README or to the pr description devdocs section ?
i see we have a demo showing how to register search strategy, but i am wondering how can i use this service if i just want to perform search ?

@@ -20,16 +20,22 @@
import { PluginInitializerContext, CoreSetup, CoreStart, Plugin } from '../../../core/public';
import { AutocompleteProviderRegister } from './autocomplete_provider';
import { DataPublicPluginSetup, DataPublicPluginStart } from './types';
import { searchService } from './search';
import { SearchService } from './search/search_service';
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why import both, or why even have searchService function, all it does is new SearchService(params) ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copied the plugin way of doing things (this was its own separate plugin so this was the index.ts file, at the plugin level, this is export plugin..., here I renamed it export searchService ...). Not necessary except for conformity. It is pretty silly when you take it outside of the plugin level. I can remove.


constructor(initializerContext: PluginInitializerContext) {}
constructor(initializerContext: PluginInitializerContext) {
this.searchService = searchService(initializerContext);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we need to create this in the constructor or could it be postponed till setup() ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could but then we'd need to store the initializerContext and make searchService possibly undefined. Is there any benefit to postponing? It was my impression that constructor and setup are all run before Kibana loads up so it doesn't make a difference which it's in. If I'm wrong I can move it.

return api;
}

public start(core: CoreStart) {}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm, how does this work ? setup() contract includes registerSearchStrategyContext and registerSearchStrategyProvider ... that makes sense

what about start method ? (i was expecting search function here)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

search functionality is passed down via AppMountContext, or RouteHandlerContext. In NP land, I can't think of a situation they will need to be access via the start contract. We exposed it in Setup just for legacy land. We think we could expose in start too (or instead of). I don't think it really matters at that point.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

exposing search in setup method means that who ever uses it has no idea if searchStrategies have been registered yet.
not exposing search in start: how can i pass search to any other plugin then ? my plugin would want to register esaggs function to expressions function registry, esaggs requires search, so we kind of need it in the contracts.

Copy link
Member

@ppisljar ppisljar Oct 9, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also ... it doesn't seem we expose it in setup currently (at least not on the client side)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yea, I honestly couldn't think of a reason to expose it, but you just gave one example. It will be interesting though because esaggs will need to use it bound to the current user.

Mind if we punt on that for this PR and then we can work on adding it in for real to replace esaggs and make the adjustments needed that way?

data: DataPublicPluginSetup;
}

declare module '../../../../../src/plugins/data/public' {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

whats this for ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

adding a comment to the file:

/**
 * Add the typescript mappings for our search strategy to the request and
 * response types. This allows typescript to require the right shapes if
 * making the call:
 * const response = context.search.search(request, {}, DEMO_SEARCH_STRATEGY);
 * 
 * If the caller does not pass in the right `request` shape, typescript will
 * complain. The caller will also get a typed response.
 */

@elasticmachine
Copy link
Contributor

💔 Build Failed

@stacey-gammon
Copy link
Contributor Author

can we add some documentation either to the README or to the pr description devdocs section ?
i see we have a demo showing how to register search strategy, but i am wondering how can i use this service if i just want to perform search ?

I don't really want to call this service out yet in devdocs given that it will likely go through so much change.

The demos do have code for searching both the ES_SEARCH_STRATEGY and the DEMO_SEARCH_STRATEGY (they do actually perform the searches). I called out the specific sections in this presentation: https://docs.google.com/presentation/d/1_nKsMnRYRTDDz6n_U7XRMfKrSEYXiNjYLMJD5ttR78o/edit#slide=id.g61fddd3178_0_3217 starting on slide 25, Hands on: using our search. The legacy, server side version is not tested, but described. The NP way of using search services is tested in the demo. lmk if you think that is sufficient.

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@ppisljar
Copy link
Member

ppisljar commented Oct 9, 2019

a demo of how can i use it in my plugin would be nice (so a plugin that does not register an application)
also a demo of how (or a slide) of how i can use it on client side in the old platform. (i was looking for npStart.plugins.search.search) something that can be used in SearchSource (which is still a legacy service)

@stacey-gammon
Copy link
Contributor Author

a demo of how can i use it in my plugin would be nice (so a plugin that does not register an application)

Yea, this would be good, do you mind if I punt on this for this PR though? I think I'm going to hit the context issues described here: #46483. And probably require some syncing with platform team. I actually would hit it when migrating to https://github.com/elastic/kibana/pull/47337/files ... since then the search_explorer would be registering a section to the living documentation plugin, which would be similar to what you are asking. Also it'd be cool to add some documentation for the interpreter using this system, and we can use it that way too.

also a demo of how (or a slide) of how i can use it on client side in the old platform. (i was looking for npStart.plugins.search.search) something that can be used in SearchSource (which is still a legacy service)

This one I'm not sure is worth pointing out in the demo plugin since we are moving away from legacy. I just pushed another commit that exposes via start contract and confirmed it worked by using it inside default_search_strategy Courier:

Screen Shot 2019-10-09 at 10 26 22 AM

Screen Shot 2019-10-09 at 10 27 28 AM

@elasticmachine
Copy link
Contributor

💔 Build Failed

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

Copy link
Member

@ppisljar ppisljar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@stacey-gammon stacey-gammon merged commit 3cb74bd into elastic:master Oct 10, 2019
stacey-gammon added a commit to stacey-gammon/kibana that referenced this pull request Oct 10, 2019
* Phase 1 of search services

* First review feedback

* Start on tests

* Add functional tests for search explorer

* Add unload and fix ts error

* Add index.test.ts files for coverage completeness

* Adding unit tests

* use internal route terminology. No reason this should be a public route, at least not yet.

* Move search service into data plugin

* App mount search context needs to be optional

* Add more unit tests for server stuff

* wip types fix

* fix types for new context container stuff

* put back all jest test coverage paths

* address review comments

* delete the two test files that just tested the instantiation of the search service

* expose search fn on StartContract... tested locally only

* update mocks to account for new startcontract
stacey-gammon added a commit that referenced this pull request Oct 10, 2019
* Phase 1 of search services

* First review feedback

* Start on tests

* Add functional tests for search explorer

* Add unload and fix ts error

* Add index.test.ts files for coverage completeness

* Adding unit tests

* use internal route terminology. No reason this should be a public route, at least not yet.

* Move search service into data plugin

* App mount search context needs to be optional

* Add more unit tests for server stuff

* wip types fix

* fix types for new context container stuff

* put back all jest test coverage paths

* address review comments

* delete the two test files that just tested the instantiation of the search service

* expose search fn on StartContract... tested locally only

* update mocks to account for new startcontract
@elasticmachine
Copy link
Contributor

💚 Build Succeeded

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
release_note:skip Skip the PR/issue when compiling release notes review v7.5.0 v8.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Data Access Search API: MVP/Phase 1
5 participants